Designed-in Security for Cyber-Physical Systems

T here are at least two types of security vulnerabilities: flawed or insufficient software behavior specifications that allow compromise—for example, authentication that is lacking or that can be spoofed—and incorrect implementation of specifications— buffer overflows being a classic example and Heartbleed being a notable recent one. The sad truth is that the state of the art in specification development and implementation doesn’t deliver secure software. So the question is, what does designed-in security mean in each case—for CPSs in particular—and what are the challenges? For software implementation, designed-in security includes programming language features that enhance security. Many securityenhancing programming language ideas have been proposed, but none have had traction in CPSs. Typechecking of data objects passed through interfaces is an example; at compile time and potentially at runtime, the runtime system analyzes which objects pass between software modules or routines and ensures that what’s passed looks like what’s expected. Types can have attributes, which let us specify interfaces whether encryption or authentication is required. However, this kind of dynamic introspection takes time. A CPS’s software component usually runs in a real-time control loop, which means it must be fast enough to keep up with a schedule. In addition, the software must have a predictable execution time, and features such as automatic garbage collection impede that. Yet, dynamic memory management errors are a common source of vulnerabilities. My hope is that we can discover a sweet spot in the spectrum of programming language features that gives real-time system designers sufficient speed, predictable behavior, and features that enhance security. I would also hope for widespread adoption of such a language by the energy industry. Frankly, I think the latter problem is more difficult owing to the many understandable but very real business impediments to change, such as the immaturity of such technology and a lack of vendor support. T he November/December 2014 issue of IEEE Security & Privacy will focus on control system security in the energy industry. As a preview, guest editors Sean Peisert and Jonathan Margulies hosted a roundtable discussion featuring three experts from the energy sector—David M. Nicol, Himanshu Khurana, and Chris Sawall—who offer different perspectives on the meaning and challenges of “designed-in security”: one from academia, one from a cyber-physical system (CPS) provider, and one from an end asset owner and user. Like the parable of the blind men and the elephant, we get three fairly distinct viewpoints. The academic highlights foundational issues and talks about emerging technology that can help us design and implement secure software in CPSs. The provider’s view includes components of the academic view but emphasizes the secure system development process and the standards that the system must satisfy. The user issues a call to action and offers ideas that will ensure progress.